<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

  <head>
    <title>Radio2ipod Tutorial</title>
    <meta name="AppleTitle" content="Radio2ipod Tutorial"/>
    <meta name="AppleIcon" content="images/radio2ipod-icon-16x16.png"/>
    <link href="styles/styles.css" rel="stylesheet" media="all" type="text/css" />
  </head>

  <body>
    <div id="frame">
      <div id="contentleft">
        <center>
          <img src="images/radio2ipod-icon.png" alt="Application Icon" border="0" />

          <h1>Radio2ipod Tutorial</h1>

        </center>
      </div>

      <div id="contentcenter"></div>

      <div id="contentright">
        <h2>Help Topics</h2>
<!-- By "tutorial", we mean walking the user through a concrete example 
     of using the product to do a specific task. A lot of manuals skip 
     this in favor of giving abstract instructions for how to do 
     something, but not all brains can learn that way. For many people, 
     a step-by-step tutorial is the only thing that helps them "get it." 
     So, even though some users will never need or read the tutorial 
     sections, they can mean the difference between a new user who 
     actually uses the product and one who never gets past opening the box.

     A few tips on good tutorials:
     * Choose examples that best reflect what most new users will want to do.
     * Keep the cognitive overhead as low as possible by NOT using an example 
       that requires domain-specific knowledge. For example, a tutorial on a 
       desktop publishing program would be better using a pizza shop as the 
       scenario rather than, say, a tax attorney. The learner should be able 
       to focus 100% of their brain cells on doing the tutorial and not a 
       single neuron wasted in figuring out why that particular business would 
       need to do that particular thing...
     * Include a LOT of them. Some of us learn by "triangulation".
     * Watch for cliffs! The deal-killer in a tutorial is when a crucial 
       piece--however small--is left out either inadvertently or because the 
       author assumed this part of the step was so frickin' obvious. Of course, 
       the level of granularity you choose for a "part" depends on who your 
       audience is. Most software apps today should not have to explain how a 
       mouse works, for example; a lot of pre-existing user knowledge is rightly 
       encapsulated in the "Select FOO from the BAR menu..." But, rarely do 
       people complain that the manual contained too many step-by-step details. 
       For most of us, the pain starts when we suddenly turn the page and say, 
       "Uh... what did I just miss? How the hell did they get THERE? My dialog 
       box looks nothing like that..."
     (If you want to know more about making good tutorials, a great place to 
     look is at the Visual QuickStart Guides like the ones Tom and Dori write.) 
     Knowledge in the Head vs. Knowledge in the World

     When we're talking about memory, we have to define what should be remembered, 
     and what should exist Out There. Clearly, the more we can rely on external 
     clues the better, and there's no reason we should have to memorize the 
     reference steps for doing something we'll never do again, but we have to 
     memorize some things. The trick is to figure out what. What will make their 
     experience much better if they just know it?

     Don Norman talks about defining the difference between Knowledge in the World 
     (external clues) vs. Knowledge in the Head (things you memorize and "know"). 
     Although he's talking about product design, it applies to manuals and to the 
     relationship between the product and the manual.-->
      </div>
    </div>
  </body>
</html>